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CHAPTER  1 
INTRODUCTION 

1.1  PROBLEM  DEFINITION 

The  information  and  data  handled  by  each  part  of  a  C3I  (Command,  Control, 
Communication  and  Intelligence)  system  are  complex  and  numerous  and  it  is  difficult  for  the 
commander  to  get  an  accurate  view  of  what  happens  on  the  battlefield.  Information  has  to  be 
fused  in  order  to  avoid  the  accumulation  of  useless  or  redundant  data.  Another  problem  is  that 
each  pan  of  the  system  has  its  own  particular  interests  and  concerns  in  his  battlefield  area  which 
are  not  always  the  main  concern  or  the  interest  of  the  system  in  a  whole.  Therefore,  a  need  exists 
to  coordinate  all  these  pans  to  make  the  system  effective  and  this  coordination  has  to  be  taken 
into  account  at  the  design  stage  with  the  formulation  of  the  requirements 

The  determination  of  the  functional  requirements  of  a  system  is  usually  done  by  representing 
the  relationships  among  the  different  processes  which  have  to  take  place  for  the  execution  of  a 
mission.  C3I  systems  are,  among  other  characteristics,  geographically  dispersed  and  this 
dispersion  of  the  resources,  processes  and  communication  is  a  critical  aspect.  Therefore, 
requirements  must  include  not  only  the  processes,  but  also  the  communications  among  the 
different  parts  of  the  system. 

The  Cube  Tool  has  been  developed  as  a  methodology  for  deriving  the  processing  and 
communication  needs  for  each  system  function.  It  is  used  to  define  the  tasks  to  be  performed,  the 
resources  needed  to  perform  these  tasks,  and  the  time  when  these  tasks  are  performed.  Focusing 
on  both  processing  and  communication,  this  methodology  can  define  clearly  what  the 
requirements  are  for  each  system  function. 

The  aim  of  this  report  is  to  present  an  extension  of  Cube  Tool  for  representing  the 
requirements  for  a  given  scenario.  It  presents  how  to  generate  a  Petri  Net  representation  of  the 
responsibilities  for  each  function  and  then  how  to  derive  the  Petri  Net  of  the  requirements  for  a 
scenario,  when  the  functions  are  linked  together  to  make  possible  the  tulfillment  of  as  specific 
mission,  For  different  modes  of  operation,  a  Colored  Petri  Net  representation  of  the  requirements 
can  be  deduced  by  folding  the  Petri  Net  representation  of  requirements  for  each  mode  of 
operation, 


1 THE  REPORT  IN  OUTLINE 


Chapter  2  describes  briefly  the  theory  of  Ordinary  Petri  Nets  and  Colored  Petri  Nets, 
focusing  only  on  the  aspects  which  are  used  to  represent  the  requirements  of  a  system.  Then, 
Chapter  3  introduces  the  Cube  Tool  and  shows  how  the  processing  and  communication  needs  are 
derived  for  each  system  function.  In  Chapter  4,  a  methodology  for  going  from  the  Cube  Tool 
formalism  to  a  Petri  Net  representation  of  the  requirements  is  presented.  It  is  then  extended  to 
generate  the  Colored  Petri  Net  representation  of  the  requirements  for  several  modes  of  operation. 
This  methodology  is  applied  to  a  realistic  example  in  Chapter  5,  where  a  system  for  Air 
Interdiction  Mission  Planning  is  specified  using  Cube  Tool.  The  Petri  Nets  of  the  system 
functions  are  derived  and  merged  to  generate  the  Petri  Net  of  the  requirements  of  the  system  for  a 
given  scenario.  Finally,  conclusions  are  drawn  in  Chapter  6  and  directions  for  future  research  are 
presented. 
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CHAPTER  2 


PETRI  NETS  AND  COLORED  PETRI  NETS 


2.0  INTRODUCTION 


Petri  Nets  (Peterson,  1980;  Reisig,  1985)  are  used  for  the  modeling  and  the  analysis  of 
concurrent  and  asynchronous  processes.  Their  fields  of  application  range  from  the  modeling  of 
manufacturing  processes  to  the  representation  of  the  flow-charts  of  complex  computer  software. 
They  have  been  successfully  used  for  the  modeling  of  decisionmaking  organizations  (Remy  et 
al.,  1988)  since  they  provide  an  explicit  representation  of  the  interactions  among  decisionmakers. 

Petri  Nets  have  been  introduced  in  the  modeling  of  Distributed  Systems  because  they  give  a 
graph-theoretic  representation  of  the  communication  and  control  patterns,  and  a  mathematical 
framework  for  analysis  and  validation.  Petri  Net  modeling  is  appealing  for  the  following  reasons: 
Petri  Nets  provide  an  integrated  methodology,  with  well  developed  theoretical  and  analytical 
foundations,  for  modeling  physical  systems  together  with  complex  cognitive  decision  processes, 
and  they  capture  the  precedence  relations  and  structural  interactions  of  concurrent  and 
asynchronous  events.  Deadlocks  and  conflicts  can  be  easily  identified  on  a  Petri  Net  since  the 
graphical  nature  of  Petri  Nets  helps  to  visualize  easily  the  complexity  of  the  system.  Thus,  they 
are  appealing  to  the  la>man  as  well  as  to  the  analyst.  Various  extensions  of  the  basic  theory'  allow 
for  quantitative  analysis  of  resource  utilization,  throughput  rate,  effect  of  failures,  and  real  time 
implementation. 

First,  the  theory  of  Ordinary  Petri  Nets  will  be  presented,  followed  by  a  discussion  on  its 
limitations  and,  finally,  Colored  Petri  Nets  (Jensen,  1986)  will  be  introduced. 

2.1  ORDINARY  PETRI  NETS 

2.1.1  Definitions 
Definition  2. 1 

A  Petri  Net  -  denoted  by  PN  -  is  a  bipartite  directed  graph  represented  by  a  quadruple 
PN  =  (P,  T,  I,  0)  where  : 
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•  P  =  {pi,  ....  pn)  is  a  finite  set  of  n  places.  A  place  is  depicted  by  a  circle  node  and 
models  a  resource,  a  buffer,  or  a  condition. 

•  T=  { 1 1 . tm)  is  a  finite  set  of  m  transitions.  A  transition  is  represented  by  a  bar  node 

and  stands  for  a  process,  an  event,  or  an  algorithm. 

•  I  is  a  mapping  PxT  ->  (0,1)  corresponding  to  the  set  of  directed  arcs  -  called 
connectors  -  from  places  to  transitions.  I(pi,  tj)  =  1  means  that  there  exists  a  connector 
from  the  place  pi  to  the  transition  tj  which  indicates  that  the  process  tj  requires  the 
availability  of  the  resource  pi,  the  fulfillment  of  the  condition  pi,  or  the  availability  of 
information  in  the  buffer  pi,  in  order  to  occur. 

•  0  is  a  mapping  TxP  ->  {0,1 )  corresponding  to  the  set  of  connectors  from  transitions  to 
places.  0(tj,  pi)  =  1  means  that  there  exists  a  connector  from  the  transition  tj  to  the  place 
pi  which  indicates  that  when  the  process  tj  is  finished,  it  either  enables  the  condition  pi, 
makes  the  resource  pi  available,  or  sends  an  item  of  information  to  the  buffer  pi. 


An  example  of  a  Petri  Net,  PN  1 ,  is  shown  in  Figure  2. 1 . 


In  this  example,  we  have  : 
P  =  (pi,  p2,  p3,  p4), 

T  =  (tl,  t2,  t3 } , 


I(pl.tl)  =  1 
Kpl.  t2)  =  0 
Kpl.  t3)  =  0 


l(p2,  tl)  =  0 
I(p2,  t2)  =  1 
Kp2.t3)  =  0 


I(p3,  tl)  =  0 
I(p3,  t2)  =  0 
I(p3,  t3)  =  1 


I(p4,  tl)  =  0 
I(p4,  t2)  =  0 
I(p4,  t3)  =  0 


0(tl ,  p  1 )  =  0 
0(tl,p2)=  1 
0(tl,  p3)  =  1 
0(tl,  p4)  =  0 


0(t2,  pi)  =  0 
0(t2,p2)  =0 

0(t2,  P3)  =  0 
0(t2,  p4)  =  1 


0(t3,  pi)  =  0 
0(t3,  p2)  =  0 
Oft3,  p3)  =  0 
0(t3.  p4)  =  1 
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Definition  2.2 

A  Petri  Net  is  pure  if  and  only  if  it  has  no  self  loops,  i.e.,  no  place  that  can  be  both  an  input 
and  an  output  of  the  same  transition. 

The  net  of  Fig.  2.1  is  pure  and  all  Petri  Nets  that  are  considered  in  this  report  are  pure. 
Definition  2.3 

A  path  is  a  set  of  k  nodes  and  k  -  1  connectors,  for  some  integer  k,  such  that  the  i-th 
connector  either  connects  the  i-th  node  to  the  i+l-th  node  or  the  (i  +  l)-th  node  to  the  i-th  node. 
The  path  is  directed  if  the  i-th  connector  connects  the  i-th  node  to  the  (i  +  l)-th  node  for  all 
i  =  1  ,..k.. 

For  example,  in  Figure  2.1: 
pi  -  tl  -  p2  -  t2  -  p4  is  a  directed  path, 
p4  -  t3  -  p3  is  not  a  directed  path. 

If  a  Petri  Net  has  sources  and  sinks,  then  any  path  from  a  source  to  the  sink  is  called  an 
information  flow  path.  If  an  information  flow  path  is  a  set  of  k  nodes  such  that  the  k  nodes  are 
distinct,  then  the  information  flow  path  is  said  to  be  simple. 

In  the  example  shown  on  Figure  2.1,  the  source  of  the  net  is  place  pi,  the  sink  is  place  p4 
and  the  simple  information  flow  paths  are: 

Simple  path  I:  pi  -  tl  -  p2  -  t2  -  p4 
Simple  path  2:  pi  -  tl  -  p3  -  t3  -  p4 

Definition  2.4 

A  Petri  Net  is  connected  if  and  only  if  there  exists  a  path  -  not  necessarily  directed  -  from 
any  node  to  any  other  node. 

Fig.  2.1  depicts  a  connected  net.  Intuitively,  this  definition  formalizes  the  idea  that  a  Petri 
Net  models  a  whole  system.  There  are  no  partitions  of  the  set  of  nodes  into  disjoint  subsets,  such 
that  the  nodes  in  one  subset  are  not  connected  to  the  other  subsets. 

Definition  2.5 

A  Petn  Net  is  strongly  connected  if  and  only  if  there  exists  a  directed  path  from  any  node  to 
any  other  node. 

The  net  of  Fig.  2.1  is  not  strongly  connected  as  exemplified  by  the  lack  of  directed  path 
from  p2  to  p3.  Nets  with  sources  and  sinks  are  not  strongly  connected. 
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Definition  2.6 

The  slices  of  a  Pern  Net  (Hillion  and  Levis,  1987)  are  the  sets  of  places  or  transition  which 
represent  concurrent  activity  in  the  process  modeled  by  this  Petri  Net.  •  ^ 

The  net  of  Figure  2.1  has  two  slices: 

Slice  1:  tl 
Slice  2:  t2,  t3 

2.1.2  Petri  Nets  with  Markings 

A  Petri  N  A  can  contain  tokens.  Tokens  are  depicted  graphically  by  indistinguishable  dots 
(*),  and  reside  in  places.  The  existence  of  one  or  more  tokens  represents  either  the  availability  of 
the  resource,  or  the  fulfillment  of  the  condition,  or  the  number  of  items  of  information  in  the 
buffer.  The  travel  of  tokens  through  the  net  is  controlled  by  the  transitions.  A  marking  of  a  Petri 
Net  is  a  mapping  M  that  assigns  a  non  negative  integer  (the  number  of  tokens)  to  each  place. 
Consider  the  Petri  Net  in  Fig.  2.2. 


The  marking  is:  M(pl)  =  1;  M(p2)  =  M(p3)  =  M(p4)  =  0. 

Definition  2.7 

A  transition  is  enabled  by  a  marking,  if  and  only  if  all  of  its  input  places  contain  at  least  one 
token. 

On  Fig.  2.2,  tl  is  enabled.  All  the  conditions  to  be  satisfied  are  fulfilled. 

Definition  2.8 

An  enabled  transition  can  fire.  The  firing  of  the  transition  corresponds  to  the  execution  of  the 
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process  represented  by  the  transition  or  the  algorithm  contained  in  it.  The  dynamical  behavior  of 
the  system  is  embedded  in  the  movement  of  the  tokens;  when  the  firing  takes  place,  a  new 
marking  is  obtained  by  removing  a  token  from  each  input  place  and  adding  a  token  to  each  output 
place. 

In  Fig.  2.2,  if  tl  fires,  then  the  resulting  marking  is  shown  in  Fig.  2.3. 


Transitions  t3  and  t2  are  now  enabled.  If  they  both  fire,  the  new  marking  is  shown  in 
Figure  2.4. 


Remark:  A  transition  may  fire  concurrently  more  than  one  token,  i.e.,  a  process  may  handle 
several  tasks  simultaneously.  Each  firing  of  a  transition  is  thus  characterized  by  an  integer  k,  the 
firing  pattern  of  the  transition.  A  transinon  can  fire  according  to  the  firing  pattern  k,  if  and  only  if 
all  of  its  input  places  have  at  lea^t  k  tokens.  When  the  firing  takes  place,  k  tokens  are  removed 
from  each  input  place,  and  k  tokens  are  added  to  each  output  place.  The  firing  pattern  is  0  if  a 
transition  does  not  fire. 
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2.1.3  Linear  Algebraic  Approach 


So  far,  Petri  Nets  have  been  described  as  graphs.  An  alternative  and  similar  approach  can  be 
developed  using  linear  algebra  with  integer  coefficients  (Memmi  and  Roucairol,  1980). 


Definition  2  9 

A  Petri  Net  with  n  places  and  m  transitions  can  be  represented  by  a  n  x  m  matrix  C,  named 
the  Incidence  Matrix.  The  rows  correspond  to  places,  the  columns  correspond  to  transitions.  Its 
elements  are: 


Ci.j  =  0(tj,  pi)  -  I(pi.  tj),  1  <  i  <  n.  l<j<m.  (2,1) 

•  Ci.j  =  1  if  there  is  a  directed  arc  from  the  j-th  transition  to  the  i-th  place.  1  indicates  that  the 
firing  of  the  j-th  transition  adds  one  token  to  the  i-th  place. 

•  Ci.j  =  -1  if  there  is  a  directed  arc  from  the  i-th  place  to  the  j-th  transition.  -1  indicates  that 
the  firing  of  the  j-th  transition  removes  one  token  from  the  i-th  place. 

•  Ci.j  =  0  if  there  is  no  arc  from  the  j-th  transition  to  the  i-th  place. 


For  example,  the  incidence  matrix  of  the  net  on  Fig.  2. 1  is: 


tl  t2  t3 


-1 


C(PN1) 


1 

0 


0  0 
-1  0 
0  -1 
1  1 


Pi 

P2 

p3 

p4 


Properties 

•  The  marking  of  a  net  can  be  represented  by  a  n  x  1  vector  M,  where  M,  =  M(pi).  The  i-th 
entry  corresponds  to  the  number  of  tokens  in  the  i-th  place. 

•  The  firing  pattern  of  the  net  can  be  represented  by  an  m  x  1  firing  vector  F,  where  Fj  is 
the  firing  pattern  of  the  i-th  transition. 

•  Given  an  incidence  matrix  C,  an  initial  marking  M.  and  a  firing  pattern  F,  the  new 
marking  M'  is: 


.W  =  M  -*-  C  *  F. 


(2.2) 
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The  matrix  equation  that  corresponds  to  the  firing  of  the  net  on  Fig.  2.3  is: 


'o' 

r-l 

0  0  " 

“0" 

1 

A 

ro~ 

1 

1 

-1  0 

0 

1 

+ 

1 

0  -1 

0 

0 

—  — 

0 

1  1 

L2J 

M  C  F 


2.1.4  Petri  Nets  with  Switches 

For  the  modeling  of  decision  making  organizations,  switches  have  been  introduced  as  an 
extension  of  the  Petn  Net  theory  to  take  into  account  the  possible  alternatives  (Tabak  and  Levis, 
1985).  A  switch  is  a  particular  transition  with  multiple  output  places.  When  a  switch  fires,  only 
one  of  its  output  places  can  receive  a  token.  This  output  place  which  receives  the  token  is  chosen 
according  to  certain  decision  rules  associated  with  the  switch.  These  decision  rules  can  be  either 
deterministic  (the  output  place  is  a  function  of  the  input),  or  stochastic  (a  probability  distribution 
over  the  set  of  possible  output  places  is  defined).  Figure  2.5  depicts  a  Petri  Net,  PN2,  with  a 


switch  si. 


Figure  2.5  Petri  Net  PN2  with  a  Switch 

A  pure  Petri  Net  with  switches  can  be  represented  also  with  an  incidence  matrix.  Switches 
are  considered  to  be  transitions  and  appear  on  the  last  columns  of  the  matrix  Nothing  about  the 
decision  rules  of  the  switch  is  contained  in  the  matrix  representation.  The  incidence  matrix  of  the 
Petri  net  PN2  is  : 
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C(PN2) 


tl 

t2 

si 

0 

0 

-1  ‘ 

pi 

-1 

0 

1 

P- 

0 

-1 

1 

P3 

1 

1 

0 

p4 

For  the  modeling  of  decisionmaking  organizations  and  of  distributed  intelligent  systems,  a 
Petri  Net  is  a  formal  model  of  information  flow.  Tokens  can  be  considered  as  symbolic 
information  carriers;  places  are  the  nodes  where  tokens  can  stand  without  being  modified; 
transitions  and  switches  are  events  that  perform  a  transformation  on  the  information:  it  can  be  a 
transmission,  a  computation  or  a  decision;  switches  are  particular  types  of  events  that  transform 
input  information  according  to  a  certain  decision  rule. 

2.2  COLORED  PETRI  NETS 

Ordinary  Petri  Nets  present  some  problems  when  modeling  and  analyzing  a  distributed 
system.  The  first  one  is  that  a  Petri  Net  representation  of  a  real  system  can  become  very  large 
since  it  can  not  take  into  account  some  symmetries  or  repetitiveness  displayed  by  the  system.  The 
second  problem  is  the  use  of  switches  for  modeling  alternate  courses  of  actions.  When 
examining  the  dynamical  behavior  of  such  a  system,  coordination  of  the  settings  of  several 
switches  is  necessary  to  avoid  the  creation  of  deadlocks.  Monguillet  (1987)  describes  this 
problem  extensively.  Finally,  the  lack  of  differentiation  of  tokens  in  Ordinary  Petri  Nets  is  an 
important  draw-back  since  in  the  modeling  of  a  system  there  is  a  need  to  know  what  a  token 
represents  specifically  when  it  is  present  in  a  given  place. 

In  order  to  improve  the  modeling  and  analytical  power  of  Ordinary  Petri  Nets,  extensions 
called  High  Level  Nets  (Genrich  and  Lautenbach,  1981)  have  been  devised.  Two  major  models 
have  been  developed,  Predicate  Transition  Nets  (Genrich,  1987)  and  Colored  Petri  Nets  (Jensen, 
1987),  which  are  used  in  this  report.  These  models  are  based  on  common  ideas: 

•  The  tokens  can  be  differentiated.  They  have  an  identity  (color). 

«  The  identity  describes  some  information  about  the  physical  meaning  of  the  token.  If  a 
token  models  a  communications  message,  its  identity  may  be  the  pair  (Sender,  Receiver), 
which  describes  the  source  and  the  destination  of  the  message. 

•  They  provide  a  way  for  describing  the  logic  that  drives  the  control  process  of  the 
transitions. 
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2.2.1  Definitions 

Let  us  illustrate  these  notions  by  introducing  Colored  Petri  Nets,  as  defined  in  Jensen 
(1987),  which  are  used  further  in  this  report  to  model  the  requirements  of  a  system  in  different 
modes  of  functioning. 

Definition  2.10 

A  Colored  Petri  Net  (CPN)  is  given  by  (  P,  T,  C(t),  ^  x*  C(p)p  in  p,  M(p)p  m  p,  I,  O): 

•  P,  a  set  of  places.  As  in  Ordinary  Petri  Nets,  a  place  models  a  resource,  a  buffer,  or  a 
.condition,  and  is  depicted  by  a  circle  node. 

•  T,  a  set  of  transitions.  As  in  Ordinary  Petri  Nets,  a  transition  models  a  process,  an  event, 
or  an  algorithm  and  is  depicted  by  a  bar  node. 

•  Each  transition  t  has  attached  to  it  a  finite  set  of  occurrence-colors  with  7t,  elements: 

C(t)  -  {  C/til ,  ....  C(t)7tJ.  Each  occurrence  color  corresponds  to  one  firing  mode:  to  one 
pattern  of  behavior  of  the  process.  In  the  case  of  Ordinary  Petri  Nets,  when  a  process 
offers  s  >  1  courses  of  action,  it  is  modeled  by  a  switch  with  s  branches.  In  the  case  of 
Colored  Petri  Nets,  every  process  is  modeled  by  a  transition  and  the  set  C(t)  keeps  track  of 
the  alternative  courses  of  action. 

•  Each  place  has  attached  to  it  a  finite  set  of  token-colors  with  np  elements. 

C(p )  =  (C(p)l ,  ,.,C(p)KpJ .  Each  token  color  corresponds  to  one  type  of  information 
content  attached  to  a  token.  Only  tokens  that  have  their  color  in  C(p)  can  be  placed  in  p  and 
one  place  can  simultaneously  contain  several  tokens  with  the  same  color.  Conversely,  one 
place  can  contain  tokens  of  different  types,  provided  that  their  color  belongs  to  C(p). 

•  The  marking  of  a  place  is  a  7tpx  1  vector  NI(p). 

M(p)  -  [fij,  . fizp]'  "'here  B,  indicates  that  p  contains  (3,  tokens  of  color  C(p)i. 

•  I(p.t)  is  a  ,Tp  x  n.  matrix  for  any  transition  t  and  any  place  p. 

The  rows  correspond  to  the  elements  of  the  set  of  token  colors,  C(p),  that  is  the  colors  of 
the  tokens  that  can  be  put  in  the  place  p.  The  columns  correspond  to  the  elements  of  the  set 
of  occurrence  colors  of  t,  C(t),  the  alternative  courses  of  actions. 

I(p,t) ,  j  describes  the  number  of  tokens  of  color  C(p)i  that  are  removed  from  the  place  p, 
when  the  transition  t  fires  according  to  the  firing  mode  j.  If  some  entries  of  I(p,  t)  are  non 
null,  an  arc  is  drawn  from  the  place  p  to  the  transition  t  in  the  graphical  representation  of 
the  Colored  Petn  Net.  This  arc  is  annotated  by  the  matrix  I(p,  t). 

•  O(p.t)  is  a  ftp  x  matrix  for  any  transidon  t  and  any  place  p. 
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The  rows  correspond  to  the  elements  of  the  set  of  token  colors,  C(p),  the  colors  of  the 
tokens  that  can  be  put  in  the  place  p.  The  columns  correspond  to  the  elements  of  the  set  of 
occurrence  colors  of  t,  C(t),  the  alternative  courses  of  actions. 

O(p.t)  j ,  describes  the  number  of  tokens  of  color  C(p)i  that  are  put  in  the  place  p,  when  the 
transition  t  fires  according  to  the  firing  mode  j.  If  some  entries  of  0(p,  t)  are  non  null,  an 
arc  is  drawn  from  the  place  p  to  the  transition  t  in  the  graphical  representation  of  the 
Colored  Petri  Net.  This  arc  is  annotated  by  the  matrix  0(p,  t). 

2.2.2  Examples 

Let  us  describe  two  examples  to  understand  the  concepts  of  Colored  Nets.  These  examples 
are  from  Demael  (1989). 

Example  1:  Product  Sorting 

Consider  a  machine  at  the  end  of  an  assembly  line.  This  assembly  line  produce  the  products 
of  type  A,  B  and  C.  The  machine  sons  these  products  and  has  to  put  them  in  appropnate  boxes 
according  to  their  types.  This  job  can  be  represented  by  a  Colored  Petri  Net  in  Figure  2.6. 


In  this  example,  places  can  contains  tokens,  which  represent  products.  It  is  thus  very  natural 
to  assume  that  the  color  of  the  tokens  belong  to  { <A>,  <B>,  <C> ) .  the  types  of  products. 


24 


Place  pi  stands  for  the  products  to  be  sorted.  Its  color  set  is  (<A>,  <B>,  <C>),  as  this 
place  can  contain  any  combination  of  products  to  be  sorted.  The  initial  conditions  depicted  on 
Figure  2.6  axe  that  two  products,  one  A  and  one  B  have  to  be  sorted. 

Place  p2  models  A's  box,  which  contains  exclusively  the  products  of  type  A, 
C(p2)  =  { < A> } .  Similarly,  p3  is  the  box  for  products  of  type  B,  and  C(p3)  =  { <B> } .  Finally, 
the  place  p4  is  the  box  for  products  of  type  C,  and  C(p4)  =  {<C>}  . 

The  transition  t  models  sorting.  The  machine  has  three  courses  of  actions,  which  have  also 
been  labeled  by  <A>,  <B>,  and  <C>.  <A>  models  the  fact  that  the  machine  is  sorting  some 
products  of  type  A,  <B>  models  sorting  products  of  type  B,  and  <C>  models  sorting  products 
of  type  C. 

The  arcs  of  the  CPN  have  been  annotated  by  the  matrices  I,  U,  V,  W,  where  I  is 

<A>  <B>  <C> 

1  0  0  1<A> 

1  =  0  1  0  <B> 

0  0  1  J<c> 

I  indicates  that  the  machine  takes  only  one  rroduct  A  when  he  sorts  products  of  type  A,  that 
it  takes  one  product  B  when  it  sons  products  of  type  B,  and  that  it  takes  only  one  product  C 
when  it  sorts  products  of  type  C.  The  other  matrices  that  annotate  the  arcs  are: 

(A)  (B)  (C)  (A)  (B)  (C)  (A)  (B)  (C) 

U  =  [1  0  0]  V  =  [0  1  0]  W=[0  0  1). 

The  matnx  U  indicates  that  one  product  is  put  into  the  box  of  products  of  type  A  only  if  the 
machine  sons  products  of  type  A,  V  indicates  that  one  product  is  put  into  the  box  of  products  of 
type  B  only  if  the  machine  sons  products  of  type  B.  W  indicates  that  one  product  is  put  into  the 
box  of  products  of  type  C  only  if  the  machine  sorts  products  of  type  C. 

This  example  is  simple,  because  the  token-colors  are  intuitive,  and  because  the  firing  modes 
of  t  correspond  exactly  to  the  token-colors.  The  next  example  describes  a  Colored  Petri  Net  that 
is  less  obvious. 


Example  2 


Figure  2.7  represents  another  Colored  Petri  Net. 

The  set  of  places  is  P  =  (pi,  p2,  p3,  p4,  p5). 

The  set  of  transitions  is  T  =  { tl ,  t2,  t3 } . 

The  set  of  token-colors  for  pi  and  p2  is  A  =  (al,  a2}. 

The  set  of  token-colors  for  p3  and  p4  is  B  =  {  bl,  b2). 

The  set  of  token  colors  for  p5  is  C  =  (cl,  c2,  c3 } . 

The  transitions  tl  and  t2  have  two  firing  modes,  which  are  labeled  1  and  2. 
The  transition  t3  has  three  firing  modes,  which  are  labeled  1,  2,  and  3. 


Fig.  2,7  Colored  Petri  Net 


where  the  matrices  that  annotate  the  arcs  are 


1  1  1 
0  0  0 

0  0  0. 


1 1  ' 1  i  i  , ,  _ :  i  o]  . , 

L1  o  l ;  L~  !  o  i !’  L3  ~ 


!  l  i  o:  . .  ;  l  o  oj  T . 
o  i  i  •  u=!o  i  i  •  L5  = 

L  J  L 


•  LI  indicates  that  the  first  firing  mode  of  tl  (first  column  of  LI)  removes  one  token  of  color 
al  from  pi,  and  places  one  token  in  p2.  The  second  firing  mode  (second  column)  removes 
one  token  of  color  al  and  one  token  of  color  a2,  and  places  both  in  p2  . 

•  L2  indicates  that  the  first  firing  mode  of  t2  removes  one  token  of  color  bl  from  p3,  and 
places  it  in  p4,  The  second  firing  mode  removes  a  token  of  color  b2,  and  places  it  in  p4. 

•  L3  indicates  that  the  first  two  firing  modes  of  t3  remove  one  token  of  color  al  from  p2, 
The  third  firing  mode  removes  one  token  of  color  a2. 
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•  L4  indicates  that  the  first  finng  mode  of  t3  removes  one  token  of  color  hi  from  p4.  The 
other  two  firing  modes  remove  one  token  of  color  b2. 

•  L5  indicates  that  all  firing  modes  of  t3  place  one  token  of  color  cl  in  p5. 

This  example  shows  how  to  deal  with  tokens  of  different  colors  and  how  they  can  be 
combined  together.  For  example,  the  first  finng  mode  of  t3  shows  that  a  token  of  color  al  has  to 
be  removed  from  p2  and  a  token  of  color  bl  from  p4  to  produce  a  token  of  color  cl  in  p5  with 
al,  bl  and  cl  belonging  to  different  sets  of  token-colors. 

2.2.3  Firing  Rules 

The  firing  rules  for  Colored  Nets  are  similar  to  those  of  Ordinary  Petri  Nets.  The  firing 
mode  C(t)i  is  enabled  for  the  transition  t  if  and  only  if  each  input  place  of  t  contains  at  least  the 
colored  tokens  that  are  indicated  by  the  i-th  column  of  I(p.t').  An  enabled  transition  can  fire  if  at 
least  one  of  its  firing  modes  is  enabled.  If  the  transition  t  fires  according  to  the  firing  mode  C(t)i. 
the  colored  tokens  that  are  indicated  by  the  i-th  column  of  l(p,t)  are  removed  from  each  input 
place  p.  For  each  output  place  p'.  colored  tokens  that  correspond  to  the  i-th  column  of  0(p',t)  are 
added  to  the  place  p'. 

One  transition  may  fire  concurrently  according  to  several  modes,  i.e.,  a  process  may  be  able 
to  handle  tasks  of  a  different  nanire  at  the  same  rime.  Within  each  category,  i.e.,  given  one  firing 
mode,  several  tasks  of  the  same  nature  may  be  processed  concurrently.  The  firing  pattern  of  a 
transition  in  a  Colored  Petri  Net  is  thus  given  by  a  n,xl  vector  F,,  where  IF,],  describes  the 
number  of  concurrent  activations  of  the  i-th  firing  mode.  If  the  firing  pattern  of  the  transition  is 
F,  then  the  combination  of  colored  tokens  indicated  by  the  i-th  column  of  I(p,  t)  is  removed  [Ft], 
times  from  each  input  place  p.  Similarly,  the  combination  of  colored  tokens  indicated  by  the  i-th 
column  of  I(p',  t)  is  added  [FJ,  times  to  every  output  place  p'. 

In  the  CPN  of  Fig  2.7,  only  the  first  mode  of  tl  and  the  second  mode  of  t2  are  enabled: 

•  The  input  place  of  tl,  pi ,  contains  only  one  token  of  color  al .  LI,  the  annotation  of  the 
adjacent  arc  is: 


The  finng  mode  1  removes  one  token  of  color  al .  The  initial  marking  of  p  1  enables  this 
firing  mode.  This  is  not  the  case  for  firing  mode  2.  because  pi  does  not  contain  a  token  of 


color  a2.  Finally,  as  pi  contains  one  and  only  one  token  of  color  al,  tl  can  process  at 
most  one  task  al,  and  F(t),  is  either  0  or  1. 

•  The  input  place  of  t2.  p3.  contains  only  one  token  of  color  b2.  L2,  the  annotation  of  the 
adjacent  arc  is: 

1  2 


L2  =1 


0 


?! 


bl 

b2 


Firing  mode  1  removes  one  token  of  color  bl.  The  marking  of  p3  does  not  enable  this 
firing  mode.  This  is  not  the  case  for  Firing  mode  2,  because  p3  does  contain  a  token  of 
color  b2.  Finally,  as  p3  contains  one  and  only  one  token  of  color  b2,  t2  can  process  at 
most  one  task  b2.  and  F(  t)2  is  either  0  or  1. 

If  tl  fires  according  to  the  firing  mode  1,  and  t2  according  to  its  firing  mode  2,  the  marking 
of  the  net  is  changed  into  the  marking  of  Figure  2.8. 


Fig.  2.8  Colored  Petri  Net  after  Firing 


2.2.4  Incidence  Matrix 

A  Colored  Petri  Net  with  n  places  and  m  transitions  can  be  represented  by  a  n  x  m  block 
matrix  C:  the  Incidence  Matrix.  The  entries  of  the  matrix  are  themselves  matrices. 

The  rows  correspond  to  places,  the  columns  correspond  to  transitions. 

•  Ci.j  =  O(t.p),  if  there  is  a  directed  arc  from  the  j-th  transition  to  the  i-th  place.  0(t,p) 
indicates  the  colored  tokens  that  can  be  added,  as  determined  by  the  Firing  modes. 
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•  Cu  =  -Ht.pt.  it’  there  is  a  directed  arc  from  the  i-th  place  to  the  j-th  transition.  - 1  ( t ,  p ) 
indicates  the  colored  tokens  that  can  be  removed,  as  determined  by  the  firing  modes. 

•  Cm  -  Null  matrix,  if  there  are  no  arcs. 

The  marking  of  a  net  can  be  represented  by  a  nxl  block  vector  M ,  where  Mj  =  M(pi).  The 
i-th  entry  corresponds  to  the  colored  tokens  in  the  i-th  place.The  i-th  entry  is  thus  a  column  with 
one  row  for  each  element  of  C(pi). 

Given  an  incidence  matrix  C,  an  initial  marking  M,  and  a  firing  pattern  F,  the  new'  marking 
is: 

NT  =  M  +  C  *  F  (2.3) 


The  Colored  Petri  Net  of  Fig.  2.7  has  the  following  Incidence  matrix: 


C  = 


0  0  1 
0  -L3 

-L2  0 

L2  -L4 
0  L5 


The  initial  marking  is  given  by: 


M  = 


NKpl) 

NKp2) 

M(p3) 

NKp4) 

M(p5)_ 


with  M(pl)  =  M(p3)  = 


'o' 

1 

M(p2)  =  M(p4)  = 

o 

.  M(p5)  = 

0 

L 

_0_ 

The  place  pi  contains  only  one  token  of  color  al,  p3  contains  only  one  token  of  color  b2,  p2 
and  p4  contain  no  tokens,  and  p5  contains  only  one  token  of  color  cl.  Finally,  the  firing  pattern 
of  Fig.  2.8  corresponds  to 


"fi" 

..ri  [l] 

,  with  FI  =  |  0 

"o’ 

.1. 

V 

F  = 

F2 

,  F2  = 

,  F3  = 

0 

_F3_ 

.0. 
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By  i 

applying  (2. 

M\pl) 

3)  the  new  marking  NT  is  obtained: 

r.i 

M'lp2) 

r0i  i  1  1 

r0i 

M  = 

M'(p3) 

,  with  M'(pl)  =  M'(p3)  -  1  !,  M'(p2)  =  i  1, 

M'(p4)  =  1  !, 

M'(p5)  =  |  0  | 

M'(p4) 

_  M'(p5)_ 

1 - 

lo 

L]J 

L°J 

This  chapter  introduced  basic  concepts  of  Ordinary  Petri  Net  theory’  and  Colored  Petri  Net 
theory.  Only  the  notions  that  are  of  relevance  in  the  subsequent  chapters  have  been  defined. 


CHAPTER  3 


THE  CUBE  TOOL  METHODOLOGY 


3.0  INTRODUCTION 

C3I  (Command.  Control,  Communication  and  Intelligence)  systems  arc  distributed  systems 
in  the  sense  that  they  are  geographically  dispersed.  They  involve  a  time-dimension  which  can  be 
evolutionary'  and  cover  a  multiplicity  of  different  operational  domains.  Such  systems  must  allow 
for  technical  and  functional  reconfiguration  and  an  evolutionary  implementation.  These  systems 
associate  operators,  software,  hardware,  facilities  and  procedures  which  are  organized  to  satisfy 
a  set  of  specific  needs  and  are  subject  to  technical  and  operational  constraints.  Therefore,  a 
method  for  designing  C3I  systems  has  to  take  into  account  all  the  human  and  technical  aspects. 

Cube  Tool  (Toumes,  1988)  is  a  methodology  developed  at  THOMSON-CSF  in  France  for 
the  design  and  the  analysis  of  C3I  systems.  The  methodology  allows  for  (1)  the  qualitative  and 
quantitative  design  of  the  architecture  of  C3I  systems;  (2)  the  determination  of  the  characteristics 
of  the  elements,  which  are  known  also  as  the  attributes  or  parameters  of  the  system;  and  (3)  the 
definition  of  the  general  plan  for  realization.  The  Cube  Tool  covers  the  application  domains 
which  are  common  to  all  C3I  systems:  communication,  information  processing,  information 
storage,  supervision/management,  and  man/machine  interface.  The  application  of  Cube  Tool  to 
the  design  and  the  analysis  of  a  system  is  done  in  four  steps,  as  shown  in  Figure  3.1. 

•  Identification  of  the  system  Functions  and  of  the  different  Actors  or  resources  (personnel 
and  hardware/software)  involved, 

•  Functional  Analysis  for  the  determination  of  the  processing  and  information  exchanges  for 
each  function, 

•  Quantitative  Evaluation  of  Automated  Data  Processing  (ADP)  and  communication  loads  in 
workstations, 

•  Consideration  of  Alternative  Architectures  through  the  allocation  of  functions  to  different 
sites. 
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Figure  3. 1  MethodoSocv  Flow  Chan 
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3  !  STEP  1:  SYSTEM  FUNCTION  AND  ACTOR  IDENTIFICATION 


The  first  stage  of  Cube  Tool  consists  of  identifying  the  functions  of  the  system  to  be 
designed.  Simultaneously,  the  resources  needed  for  the  execution  of  these  functions  are  defined. 
They  consist  of  personnel  and  hard  ware/s  oft  ware  entities  such  as  databases  or  decision  aids  and 
are  referred  to  as  Actors.  At  this  stage,  the  designer  must  find  out  the  user  needs,  the  type  of 
missions  the  system  will  have  to  accomplish,  and  the  personnel  and  types  of  hardware  and 
software  which  will  be  used.  This  process  requires  intensive  interviews  with  the  user  to 
determine  exactly  what  the  range  of  operations  of  the  system  will  be.  The  missions  that  the 
system  is  expected  to  carry  out  are  determined  and  are  used  as  the  basis  for  the  identification  of 
the  global  tasks  that  must  be  executed  for  the  fulfillment  of  a  mission.  These  global  tasks  are  the 
system  Functions.  For  example,  a  system  for  planning  an  air  interdiction  mission  will  have  as 
functions  the  determination  of  the  status  of  allied  forces,  weather  projection,  threat  assessment, 
strike  assessment,  intelligence  report  processing,  target  prioritization  and  development,  weapon 
system  availability,  etc. 

Then,  each  system  function  can  be  decomposed  in  subfunctions.  The  processing  tasks  are 
differentiated  from  the  transmission  tasks.  A  processing  task  only  involves  the  processing  of  data 
received  by  an  actor  in  charge  of  creating  or  inferring  new  information.  Transmission  tasks  only 
involve  the  communication  of  information  between  two  different  actors  without  any  alteration  in 
the  content.  A  function  can  be  considered  to  be  an  interleaved  sequence  of  processing  and 
communication  tasks,  a  subfunction  can  be  defined  as  a  single  pair  consisting  of  a  process  task 
ar.d  a  communication  task.  The  execution  of  a  function  will  require  the  sequential  execution  of  its 
subfunctions. 

3.2  STEP  2:  FUNCTIONAL  ANALYSIS 

In  a  second  stage,  a  functional  analysis  is  performed  for  each  function  in  a  three  dimensional 
space,  as  shown  on  Figure  3.2.  The  three  axes  of  interest  are  : 

•  Functions:  These  are  the  processes  which  have  to  be  executed  for  the  fulfillment  of  the 
mission. 

•  Actors  or  Hierarchical  Levels:  These  are  the  personnel  and  the  hardware  and  software  nodes 
responsible  for  executing  the  different  tasks.  Personnel  are  layered  in  hierarchical  levels  and 
are  most  of  the  time  specialized  per  functional  domain 

•  Time:  This  axis  shows  on  the  same  scale  the  execution  time  of  the  functions,  their  frequency 
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and  tr.eir  sequence. 


Figure  3.2  Three-Dimensional  Functional  Analysis 

In  this  framework,  subfuncrions  are  defined  as  a  collection  of  activities  with  their  interrelated 
information  exchanges.  An  activity  is  defined  as  a  process  which  supports  a  given  system 
subfunction  and  which  is  performed  by  a  single  actor  or  hierarchical  level  without  major 
interruption.  Therefore,  activities  can  be  part  of  a  processing  task,  a  communication  task,  or 
contain  elements  of  both.  An  activity  is  thus  represented  as  a  cell  in  the  three  dimensional  space. 
The  functional  analysis  is  performed  by  considering  the  projection  of  the  cells  on  each  of  the 
three  planes  defined  by  the  axes  taken  two  by  two,  as  shown  on  Figure  3.2.  These  analysis 
planes  are  shown  on  Figure  3.3.  These  are: 

•  Responsibilities  Plane  (Functions  /  Actors):  This  plane  shows  which  actor  is  in  charge  of  a 
set  of  specific  activities. 

•  Sequences  Plane  (Functions  /  Time):  This  plane  shows  when  and  how  many  times  an 
activity  will  be  executed. 

•  Actions  Plane  (Time  /  Actors):  The  plane  of  actions  shows  when  actors  are  busy  performing 
some  activity. 
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A  Time  (  When  0  How  many  times  ?  ) 


Figure  3.3  The  Three  Analysis  Planes 

On  each  of  the  analysis  planes  the  analysis  is  done  according  two  perspectives: 

•  The  Processing  View,  which  focuses  on  the  tasks  which  transform  information  into  new 
intormanon 

•  The  Data  View,  which  focuses  on  the  tasks  which  transmits  information  without 
modifying  them. 

To  perform  the  functional  analysis,  activities  are  differentiated  according  to  the  type  of 
recessing  they  represent  and  are  called  roles.  Tne  roles  considered  by  the  method  are: 

•  Elaborate  (E):  generate  or  transform  information. 

•  Acknowledge  (A):  receive  an  order  important  enough  to  warrant  the  generation  of  an 
acknowledgement. 

•  Check  (C):  receive  a  report  in  response  to  an  order  or  request  previously  generated 

•  Warn  (\V):  receive  information  which  does  not  require  taking  any  measures  in  the  current 
mode  of  operation. 

•  Monitor  (M):  receive  information  on  system  status  and  operations  in  support  of  command, 
control,  and  communication  resources  management. 

•  Monitor  Locally  (L):  same  as  M  but  on  a  local  basis 

•  Secure  (H):  exchange  of  secure  data  such  as  encryption  keys,  access  keys  and  certification 
mechanisms  of  users'  trustworthiness. 


The  main  analysis  is  performed  in  the  responsibility  plane.  The  roles  which  are  used  most 
and  are  the  only  ones  considered  for  the  requirements  specification  are  E,  A,  C  and  \V.  The 
responsibility  plane  is  constructed  by  allocating  the  roles  for  each  subfunction  to  the  different 
actors.  This  allocation  must  verify  the  following  rules: 

•  Roles  E  are  assigned  using  common  sense  or  in  accordance  with  the  user's  wishes.  Some 
actors  are  more  qualified  to  execute  the  processing  part  of  a  certain  subfunction  and  expertise 
can  be  used  as  a  criterion  for  the  allocation  of  roles  E  to  the  different  actors. 

•  There  is  one  and  only  one  role  E  per  subfunction,  which  means  that  there  is  one  and  only 
one  role  E  per  row  in  the  array  of  responsibilities. 

•  Then,  the  different  roles  E  have  to  be  connected  with  communication  interfaces  to  make 
possible  the  distributed  execution  of  the  function.  Communications  betw  een  two  actors  are 
represented  with  pairs  E— »X  where  X  =  A,  W  or  C: 

•  E— »A  corresponds  to  an  order  sent  from  the  actor  performing  the  role  E  to  the  actor 
performing  the  role  A 

•  E— >C  corresponds  to  a  report  in  response  to  an  order  previously  generated  sent  from 
the  actor  performing  the  role  E  to  the  actor  performing  the  role  C.  This  means  that  if 
the  pair  E— >A  exists  on  a  row,  the  pair  C<— E  has  to  be  present  in  a  row  below  as 
shown  on  Figure  3.4. 


Generate  and  send  the  order 


Figure  3.4  Order-Execution-Report  Representation  on  the  Responsibilities  Plane 

•  E— >\V  corresponds  to  the  transmission  of  a  warning,  i.e..  that  some  event  has 
happened  and  that  certain  procedures  will  have  to  take  place.  This  communication 
takes  place  usually  from  an  actor  of  higher  hierarchical  level  to  an  actor  of  lower 
hierarchical  level  but  the  notion  can  be  extended  to  the  exchange  of  data  or 
information  regardless  of  the  hierarchical  level. 
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This  is  illustrated  in  the  example  shown  on  Table  3.1. 


Table  3.1:  Responsibilities  for  a  Function  with  Six  Subfunctions  Performed  by  Four  Actors 


actor  1 

actor  2 

actor  3 

actor  4 

subfunction  1 

E 

A 

W 

subfunction  2 

c 

_ 

A 

W 

subfunction  3 

C 

E 

r~~~A 

subfunction  4 

C 

E 

subfunction  5 

C 

E 

c 

■UHI 

®  If 

Explicit  exchanges  take  place  across  columns,  between  activities  contributing  to  the 
execution  of  the  same  subfunction  (i.e.,  on  same  row).  Implicit  exchanges  occur  from  row  to 
row  between  activities  performed  by  a  single  actor.  The  interesting  aspect  of  this  methodology  is 
that  several  configurations,  differing  as  to  the  resources  used  or  reflecting  variations  in 
operational  needs,  can  be  represented  in  a  consistent  manner.  This  makes  it  possible  to  define 
different  thresholds  of  responsibilities  in  different  modes  (normal  mode  or  emergency  modes) 
and  to  point  out  how  the  reallocation  of  the  tasks  has  to  be  made  among  the  available  actors  when 
the  system  switches  from  one  mode  to  another. 

3.3  STEP  3:  QUANTITATIVE  EVALUATION  OF  ADP  AND  COMMUNICATION  LOADS 

IN  WORKSTATIONS 

The  third  step,  which  is  the  quantitative  evaluation  of  ADP  and  communication  load  in 
workstations,  is  performed  through  an  activity  specification  according  to  the  processing  view  and 
the  data  view-.  From  these  specifications,  the  quantification  can  be  made. 

3.3.1  Activity  Specification  According  to  the  Processing  View 

The  activity  specification  is  done  only  for  the  role  E.  For  the  other  roles  (A,  C,  W,  L,  M  and 
H)  a  generic  specification  is  assumed  for  each  role  and  used  independently  on  the  subfunction  to 
which  they  belong.  For  activities  of  type  E,  each  activity  is  defined  using  a  pseudo-code 
formalism  close  to  Pascal  or  ADA.  As  shown  in  the  example  displayed  on  Figure  3.5,  this 
formalism  has  an  indented  block  structure  with  an  indication  of  the  number  of  times  each  block 
loop  is  executed.  Primitives  which  define  the  nature  of  the  information  transformed  are  used  and 
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gathered  in  a  dictionary.  A  primitive  is  decomposed  in  four  parts: 

1 1 )  an  operation  on  the  information  such  as  retrieve,  update,  send,  display,  call  . . 
t.2)  the  first  Information  module  which  consists  of  the  type  of  information  (Message, 
Program,  Graphic,  Database,...)  and  the  information  name  which  references  the  data  or 
the  processing  used  throughout  the  system. 

(3)  the  direction  (to,  from,  with,  on,...) 

(4)  the  second  information  module  which  has  the  same  structure  as  the  first  one. 

Examples  of  primitives  are: 

Update  Database  Enemy_position  from  alphanumeric  MMI  Mission_Report 
Call  subroutine  Mission_Preparation  with  Enemy_Position  Data 


The  information  names  defined  in  the  two  information  modules  are  used  to  check  the 
consistency  of  processing  and  of  communication.  In  the  example  above,  Enemy_position  is 
the  name  of  the  database  recording  the  position  of  the  enemy,  Mission_report  is  a  display  and 
Mission_preparation  is  a  processing  reference. 


BEGIN  GENERAL  TASKING 
FOR  N=1  ..  N  REQUEST 

DISPLAY  ALPHANU  MIS-PREP  FROM  MSG  TARGT-REQ 
UPDDB  TARG-REQ-DATA  FROM  DISP  ALPHANU  MIS-PREP 
END  FOR 

FOR  N=1  .  N  REQUEST 
FOR  M=1  ..M  BASES 

RET  DB  BASE-POSIT-DATA 
CALL  MIS-PLN  WITH  TARG-REQ-DATA 
AND  BASE-POSIT-DATA 
UPD  DB  MIS-RESUL  FROM  PROGMIS-PLN 
END  FOR 
END  FOR 

DISP  ALPHANU  MIS-RESUL 
END  GENERAL  TASKING 


Figure  3.5  Example  of  the  Pseudo-code  Formalism 


To  make  a  quantitative  evaluation  of  the  processing  load  in  workstations,  an  average 
processing  consumption  is  associated  with  each  primitive  invokement.  These  consumptions  are 
either  computed  by  the  summation  of  elementary  instructions  or  derived  from  benchmarks  A 


38 


distinction  is  made  between  ordinary  processing  expert  system  scientific  processing, 
man-machine  interfacing  or  communication  protocols  to  ease  the  allocation  of  the  load  to  different 
workstations. 

3.3.2  Activity  Specification  According  to  the  Data  view 

The  activity  specification  is  done  by  analyzing  the  ways  information  is  displayed  and  sent 
for  the  incoming  and  outgoing  data,  for  each  activity.  As  shown  on  Figure  3.6,  these  infoimation 
Hows  include: 

•  information  exchanges  which  are  the  messages. 

•  data  retrieved  from  the  data  bases. 

•  images  which  might  be  static,  slow-moving,  or  normal  motion  images, 

•  Man  Machine  Interface  (MMIj  which  might  be  alphanumeric  or  graphic. 


Figure  3.6  Activity  Specification  from  the  Data  View' 

To  evaluate  the  communication  load  for  each  activity,  four  types  of  exchanges  are  considered: 

•  voice  communications, 

•  character  oriented  text. 

•  bit-oriented  messages. 

•  images. 
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.'.3.3  Global  Load  Evaluation 


The  activity  specification  allows  to  quantify  the  load  for  processing,  data  storage, 
man-machine  interface  manipulation,  and  communication.  Simultaneously,  a  quantification  is 
made  for  the  maximum  response  time  to  determine  the  minimum  processing  power  threshold.  By 
summing  these  results  for  each  logical  group,  which  is  the  set  of  activities  related  to  a  given 
system  function  and  performed  by  a  single  actor,  the  number  and  type  of  workstations,  the  data 
processing  requirements,  the  number  of  database  updates  and  retrievals  and  the  load  associated  to 
communication  processing  and  related  communication  flows  can  be  determined. 

3.4  STEP  4:  CONSIDERATION  OF  DIFFERENT  ARCHITECTURES 

The  last  stage  is  the  investigation  of  different  possible  architectures  through  the  allocation  of 
logical  groups  to  different  sites.  Generic  centers  are  first  defined  by  gathering  the  logical  groups 
meant  to  operate  together  and  which  are  sufficient  to  constitute  an  independent  site.  This  is  done 
in  order  to  check  data  coherency  inside  the  generic  center  but  also  among  the  different  centers. 
The  summation  of  the  related  loads  is  performed  at  the  generic  center  level  and  gives  an 
indication  of  what  would  be  the  load  of  a  centralized  center  supporting  all  the  load  of  the  system 
related  to  the  set  of  logical  groups  handled  by  this  center. 

Areas  of  responsibility  and  interest  are  assigned  to  logical  groups.  These  areas  correspond  to 
percentage  of  geographical  involvement  that  each  actor  has. 

In  the  next  step,  generic  centers  are  shared  between  several  physical  sites.  The  load  is 
mapped  proportionally  to  the  areas  of  responsibility  and  interest  assigned  to  logical  groups.  Load 
position  factors  are  applied  to  take  into  account  the  geographical  dispersion  of  the  logical  groups 
in  the  different  sites.  Simultaneously,  different  modes  of  operation  of  the  system  are  defined. 
These  modes  are  normal  or  backup  modes  which  are  a  reassignment  of  the  activities  to  different 
actors  in  case  of  emergency.  The  vertical  back-up  corresponds  to  the  reallocation  of  the  activities 
between  actors  of  different  hierarchical  levels;  the  horizontal  back-up  corresponds  to  the  the 
reallocation  of  activities  between  actors  of  same  hierarchical  level.  A  load  factor  is  also  defined 
for  each  of  these  modes  and  used  for  the  allocation  of  the  load  to  the  different  sites.  These  load 
factors  are  coefficients  with  value  larger  than  one  which,  when  multiplied  with  an  estimate  of  the 
processing  load  or  communication  load,  give  an  indication  of  the  additional  loads  due  to  (1) 
additional  communications  resulting  from  the  geographical  dispersion  of  the  processes  and  (2) 
additional  effort  to  switch  from  one  mode  of  operation  to  another.  This  is  shown  on  Figure  3.7. 
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The  load  of  the  generic  center  is  100T  When  the  load  is  distributed  among  different  sites,  load 
factors  for  geographical  dispersion  and  for  possible  switching  of  modes  are  applied.  As  a  result, 
the  sum  of  the  load  of  the  different  sites  is  larger  than  10QT. 


Time 


Figure  3.7  Load  Sharing 

This  synthesis  gives  indications  on: 

•  The  processing  loads  per  activity  in  each  site 

•  Tne  communication  loads  per  activity  in  each  site 

•  The  connectivity  matrix  for  the  sites  of  the  system  (which  site  is  connected  to  which  site?) 

•  The  coherency  for  data  processing  sharing 

•  The  total  loads  for  each  site 

•  The  total  loads  for  each  system  communication  netw-orks 

The  last  step  is  the  reallocation  of  the  load  w  ithin  these  system  sites  to  the  workstations 
according  to  the  type  of  processing  (normal,  expert,  scientific)  and  the  security  requirements. 
Different  architectures  can  be  generated  in  this  way  and  the  selection  of  the  final  one  is  made 
according  to  criteria  such  as  cost  or  ease  of  implementation.  Other  criteria  could  be  taken  into 
account  such  as  the  effectiveness  of  the  s\  stem 
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The  interesting  aspect  of  this  methodology  is  that  it  allows  to  represent  in  a  consistent  manner 
several  configurations  of  the  use  of  the  system  to  allow  it  to  adapt  to  the  availability  of  the 
resources  or  to  the  variation  of  the  operational  needs.  This  allows  to  define  different  thresholds 
of  responsibility  in  different  modes  (normal  mode  or  emergency  modes)  and  to  point  out  how  the 
reallocation  of  the  tasks  has  to  be  made  among  the  available  actors  when  the  system  switches 
from  one  mode  to  another.  For  this  report,  only  the  two  first  steps  of  the  methodology  are  of 
interest  and  are  used  for  the  specification  of  a  system  requirements.  The  next  chapter  shows  how 
to  convert  the  allocation  of  roles  into  Petri  Nets  and  how  the  detailed  requirements  of  a  system 
for  a  particular  mission  can  be  generated. 


CHAPTER  4 


PETRI  NET  REPRESENTATION  OF  REQUIREMENTS 

4.0  INTRODUCTION 

The  requirements  of  a  system  are  the  set  of  processes  which  have  to  take  place  for  the 
correct  execution  of  a  mission.  These  requirements  are  scenario-dependent  and  are  most  often 
defined  by  the  set  of  functions  with  their  sequences  and  interrelationships.  In  Valraud  and  Levis 
( 19S9),  the  requirements  are  described  by  a  Petri  Net  in  which  system  functions  are  represented 
with  transitions  and  the  data  produced  by  these  functions,  necessary  for  the  execution  of 
subsequent  functions,  with  places.  These  nodes  are  connected  together  to  model  the 
relationships  among  functions  and  to  show  what  should  be  their  order  of  execution.  This  section 
describes  how  to  develop  more  detailed  requirements  of  a  system  which  take  into  account  not 
only  the  different  processes  which  have  to  take  place,  but  also  the  communication  exchanges 
between  the  different  pans  of  the  system. 

The  Cube  Tool  can  be  used  to  define,  for  each  function,  the  processes  and  the 
communication  exchanges  among  the  different  actors  involved  in  the  execution  of  that  function. 
The  Petri  Nets  depict  graphically  these  processes  and  communication  exchanges  for  each 
function.  When  these  representations  are  linked  together  to  construct  the  requirements,  a  global 
and  consistent  graphical  representation  can  be  defined  that  lets  the  designer  or  the  analyst  take 
advantage  of  the  mathematical  framework  which  underlies  Petri  Nets. 

4.1  REPRESENTING  THE  RESPONSIBILITIES  FOR  A  FUNCTION  WITH  PETRI  NETS 

As  we  have  seen  in  the  previous  chapter,  the  first  two  steps  of  Cube  Tool  result  in  the 
definition  of  the  different  system  functions,  their  subfunctions,  and  how  the  activities 
constituting  these  subfunctions  are  allocated  to  the  different  actors  of  the  system.  For  each 
system  function,  the  responsibility  analysis  plane  defines  the  activities  performed  by  the  different 
actors.  From  this  representation,  the  generation  of  the  equivalent  Petri  Net  representation  of  the 
responsibilities  for  each  function  is  done  in  three  steps. 

In  the  first  step,  each  activity  is  depicted  by  a  transition.  The  transitions  representing  the 
activities  performed  by  the  same  actor  are  aligned  horizontally,  while  the  ones  representing  the 
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activities  belonging  to  the  same  subfunction  are  aligned  vertically.  In  other  words,  the  transpose 
of  the  array  of  responsibilities  is  obtained  and  the  non-null  elements  of  this  array  are  transformed 
into  transitions,  as  shown  in  the  Figure  4.1 . 
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Figure  4. 1  Drawing  the  Transitions  Grid 


A  label  is  attached  to  each  transition  identifying  (1)  the  function,  (2)  the  subfunction  to 
which  the  represented  activity  belongs,  (3)  the  type  of  activity  (E,  A,  C  or  W)  and  (4)  the  actor 
performing  this  activity.  For  example,  in  Figure  4.1,  the  label  1.3E3  means  that  the  activity 
represented  by  the  transition  belongs  to  subfunction  3  of  function  1,  is  of  type  E,  and  is 
pertormed  by  actor  3,  In  the  application  described  in  this  paper,  the  subfunctions  are  not 
identified  by  their  order  of  appearance  in  a  function,  but  by  the  identification  number  of  the 
processing  they  represent  throughout  the  system. 

The  second  step  is  to  add  places  between  the  transitions  representing  the  activities  performed 
by  a  single  actor  and  to  connect  them.  In  this  way,  the  implicit  information  exchanges  which  take 
place  between  the  successive  activities  performed  by  each  actor  are  modeled.  Figure  4.2  shows 
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the  net  obtained  for  the  example. 


1.1E1  1.2C1  1.6C1 


1.1W3  1.2A3  1.3E3  1 ,4C3  1.5E3  1.6W3 


1.2W4  1.3A4  1.4E4 

1-0  ■+0-cl 

Figure  4.2  Adding  Implicit  Information  Exchanges 

The  third  step  consists  of  adding  the  information  exchanges  which  take  place  among  the 
actors  for  each  subfunction.  In  the  Cube  Tool  methodology,  an  exchange  originates  from  a  role  E 
and  ends  at  a  role  A,  W  or  C  and  that  there  is  one  and  only  one  role  E  for  each  subfunction. 
Therefore,  for  each  column  of  the  Petri  Net  representation  obtained  after  the  two  first  steps,  the 
transition  representing  the  role  E  is  identified  and  is  connected  to  the  other  transitions  of  the 
columns  with  a  connector-place-connector  set.  Figure  4.3  shows  the  final  net  for  the  example. 


1.1E1  1.2C1  1.6C1 


Figure  4.3  Adding  Explicit  Information  Exchanges 


45 


4.2  MODELING  THE  REQUIREMENTS  FOR  A  SCENARIO 


The  procedures  for  modeling  the  detailed  requirements  for  a  given  scenario  is  shown  on 
Fitiure  4.4. 


Figure  4.4  Procedures  to  Model  the  Detailed  Requirements  of  a  System 


The  definition  of  a  scenario,  that  is  a  mission  to  be  carried  out,  leads  to  the  specification  cf 
the  relationships  and  sequences  of  system  functions.  For  the  fulfillment  of  a  mission,  one  can 
identify  the  system  functions  which  can  be  executed  concurrently  as  well  as  the  functions  which 
will  have  to  be  executed  first  to  trigger  the  execution  of  a  sequence  of  functions.  These 
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interrelationships  among  functions  vary  from  one  scenario  to  another.  Petri  Nets  are  used  to 
represent  the  sequencing  and  concurrency  of  functions  so  that  the  global  requirements  of  a 
system  car.  be  derived.  The  procedure  for  determining  the  detailed  requirements  starts  with  the 
definition  of  the  responsibilities  for  the  chosen  scenario.  To  list  the  functions  on  the  Functions 
axis,  the  slices  (Million  and  Levis,  1987)  of  the  Petri  Nets  representing  the  global  requirements 


arc  computed.  These  slices  represent  the  functions  which  can  be  executed  concurrently.  The 
functions  are  listed  on  this  axis  in  the  order  of  appearance  in  the  slices  list.  Then,  for  each 
function,  the  actor  which  triggers  the  execution  and  gets  the  final  report  is  identified.  This  actor  is 
designated  as  the  main  one  responsible  for  the  execution  of  this  functions.  Once  the  main  actors 
are  listed  on  the  Actor  axis,  the  responsibility  plane  for  the  scenario  can  be  constructed.  For  each 


function: 


•  A  role  E  is  placed  on  the  cell  defined  by  the  function  and  by  the  main  actor. 

•  Roles  W  are  placed  on  the  cells  defined  by  the  functions  and  by  the  main  actors  who  are 
responsible  for  the  execution  of  the  subsequent  functions  as  determined  by  the  Petri  Nets  of  the 
global  requirements. 


From  the  information  in  the  scenario  responsibilities  plane,  the  equivalent  Petri  Net  can  be 
constructed  following  the  same  procedure  that  was  used  for  the  functions.  The  next  step  is  to 
replace  each  transition  representing  a  function  with  the  equivalent  representation  of  the 
responsibilities  of  this  functions.  By  adding  the  implicit  exchanges  among  actions  for  each  actor, 
the  Petri  Net  of  the  detailed  requirements  is  constructed. 


4.3  APPLICATION  OF  THE  METHODOLOGY  TO  AN  EXAMPLE 


Let  us  consider  an  example  where  there  are  three  functions:  fl,  f2  and  f3,  and  three  actors 
t  A 1 ,  A2  and  A3).  The  responsibilities  for  each  function  are  defined  as  shown  on  Table  4.1. 

Table  4.1  Responsibility  Analysis  Planes  for  fl,  O  and  f3 
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The  derived  Petri  Nets  are  displayed  on  Figure  4.5 
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1.1E1  1.2C1  1.4C1 


0=10 


3.1A1  3.2E1 


Figure  4.5  Pern  Net  Representation  of  the  Responsibilities  for  f  1 ,  f2  and  f? 

The  scenario  specification  has  determined  that  fl  and  f2  have  to  be  executed  before  f3.  The 
Petri  Net  of  the  Global  requirements  is  shown  on  Figure  4.5.  Its  slices  are: 

Slice  1:  fl.  f2 
Slice  2:  f3 
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The  responsibilities  specification  of  each  function  show  that  A1  is  the  main  actor  for  f l,  A 2 
for  f2,  and  A3  for  f3.  The  scenario  responsibility  plane  is  constructed  by  placing  a  role  E  in  the 
cells  (fl,  AID.  (f2.  A2)  and  <f3.A3)  and  a  role  W  in  the  cells  (fl.  A3)  and  (f2,  A3),  as  shown  on 
Table  4.2. 


Table  4.2  Example  of  Scenario  Requirements 
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Figure  4.7  Scenario  Responsibilities  for  the  Example 

By  replacing  each  transition  containing  the  letter  E  with  the  Petri  Net  representation  of  the 
responsibilities  of  the  function  this  role  E  models  and  then  by  adding  the  implicit  information 
exchanges  between  the  functions  performed  by  a  single  actor,  the  representation  of  the  detailed 
requirements  is  obtained  and  shown  on  Figure  4.^. 
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Figure  4.8  Detailed  Requirements  for  the  Example 

4.4  MODELING  REQUIREMENTS  FOR  DIFFERENT  MODES  OF  OPERATION 

For  survivability  reasons,  the  system  must  be  able  to  switch  to  different  modes  of  operation. 
In  case  of  failures  in  a  workstation  or  of  partial  destruction,  the  system  has  to  be  able  to 
accomplish  its  mission.  Therefore,  the  system  designer  must  care  for  the  duplication  of  software 
and  interfaces  on  several  workstations  and  for  the  the  definition  of  the  protocols  for  different 
modes  of  functioning.  He  has  to  define  a  nominal  mode  and  back  up  modes  which  are  in  the 
Cube  Tool  framework  reassignments  of  activities  to  different  actors.  These  reassignments  are 
done  essentially  at  the  function  level  and  are  done  at  the  scenario  level  only  to  insure  consistency 
throughout  the  functions  (if  a  mode  consists  of  ignoring  one  of  the  actor,  the  designer  has  to  be 
sure  that  this  actor  is  not  involved  in  the  execution  of  any  function).  For  more  clarity,  the  taking 
into  account  of  different  modes  of  operation  will  be  described  at  the  system  level,  since  the 
procedure  will  be  the  same  at  the  scenario  level. 

For  each  mode,  there  is  a  different  allocation  of  activities  to  the  actors  for  the  definition  of 
responsibilities.  We  consider  that  the  decomposition  of  functions  in  subfunctions  remains 
unchanged  when  switching  from  one  mode  to  another.  Therefore,  a  Petri  Net  representation  of 
the  responsibilities  for  a  function  can  be  derived  for  each  mode  of  operation.  The  next  step  is  to 
fold  together  these  different  nets  to  represent  the  responsibilities  for  all  the  modes  of  operation. 
This  is  done  by  using  Colored  Petri  Nets. 


The  Colored  Petri  Nets  that  will  be  used  have  the  following  characteristics: 

•  The  color  of  the  tokens  belongs  to  the  set  of  the  modes  of  operation  { m t ,  m-> . mn) 

•  The  possible  firing  modes  are  the  modes  of  operation  of  the  system  and  correspond  to  the 
token-color  as  in  the  first  example  of  section  2.2.3. 

•  The  set  of  occurrence  colors  of  each  transition  is  constructed  as  follows:  for  each  mode 
nij.  if  the  cell  of  the  responsibility  plane,  defined  by  the  subfunction  and  the  actor,  is 
non-null  then  irij  belongs  to  the  set  of  occurrence  color  of  the  transition  representing  this 
activity,  regardless  of  the  kind  of  processing  this  activity  represents.  The 
label  of  the  colored  transition  will  indicate  what  type  of  processing  it  represents  for  the 
different  modes  of  operation.  For  example,  the  label  1.2.E1.C2.3  indicates  an  activity  of 
the  subfunction  2  of  the  function  1  performed  by  actor  3  and  which  is  of  type  E  in  mode  1 
and  of  type  C  in  mode  2. 

•  The  set  of  tokens  colors  for  each  place  and  the  matrices  that  annotate  the  arcs  are 
determined  by  considering  each  set  connector-place-connector  and  by  looking  if  the 
transitions  which  are  at  the  edge  of  this  set  are  active  during  in  the  mode  of  operation. 

Let  us  illustrate  this  with  a  simple  example: 

Let  us  consider  a  system  with  four  actors  Al,  A2,  A3  and  A4,  and  let  us  assume  that  two 
modes  of  operations  ml  and  m2  have  been  defined,  ml  is  the  nominal  mode  while  m2  is  the 
back  up  mode  when  the  actor  A2  is  unable  to  accomplish  its  tasks  because  of  failure  or 
destruction.  In  this  case  A3  has  to  do  the  job  of  A2,  and  A4  accomplishes  the  job  that  A3  is 
doing  in  the  nominal  mode.  The  responsibility  analysis  planes  for  the  function  fl  in  these  two 
modes  of  operations  are  shown  on  Table  4.3. 

Table  4.3  Responsibility  Analysis  Planes  for  fl  for  the  Two  Modes  of  Operation 


The  derived  Petri  Net  for  each  of  these  responsibility  planes  is  shown  on  Figure  4.9. 
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Figure  4.10  Colored  Petri  Net  for  fl  for  the  Modes  ml  and  m2 


The  Colored  Petri  Net  of  Figure  4.10  has  the  following  characteristics: 

The  sets  of  occurrence-colors  for  each  transition  is: 

C0.1.1E2E.1)  =  C0.2.1C2C.1)  =  C(1.4.1C2C.l)  =  {ml,  m2] 

C0.1.1A.2)  =  C(  1.1. IE. 2)  =  C0.3.1C.2)  =  C(1 .4.1E.2)  =  {ml} 

C0.1.1W2A.3)  =  C(  1.2.1  A2E.3)  =  C0.3.1E2C.3)  =  C(1.4.1W2E.3)  =  {ml,  m2] 
C0.1.2W.4)  =  CU.1.2A.4)  =  C0.3.2E.4)  =  C0.4.2W.4)  =  {m2} 

The  set  of  token-colors  for  each  place  is: 

Ctpl)  =  C(p2)  =  C(p6)  =  C(p7)  =  C(p8)  =  C< p  1 3)  =  C ( p  1 4 )  =  Cpl5.)  =  (ml,  m2] 
C(p3)  =  C(p4)  =  C(p5)  =  C(p7)  =  Ctpl 2)  =  C(pl6)  =  C(pl7)  -  Ctpl 8)  =  (ml } 
C(p9)  -  C(plO)  =  Ctpl  1 )  =  C(pl9)  =  C(p20)  =  C(p21)  =  C(p22)  =  {m2} 

The  three  possible  matrices  that  annotate  the  arcs  are: 

ml  m2  ml  m2  ml  m2 

,  _f  1  O'  ml  -  ,  1  O']  ml  .  ,  J  0  0;  ml 

l~[0  1  m2  _;0  0 ,  m2  L~",0  1  |  m2 


The  next  chapter  describes  the  application  of  the  methodology  to  a  real  example  of  C31 
svstem. 
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CHAPTERS 


EXAMPLE:  AN  AIR  INTERDICTION  MISSION  SYSTEM 


5.0  INTRODUCTION 

The  system  used  to  illustrate  the  methodology  is  a  fictitious  one  called  MESACC,  which 
stands  for  Modular,  Endurable.  Survivable,  Austere.  Command  Center  and  which  has  been 
studied  by  Valraud,  Perdu  and  Levis  and  described  in  Valraud  and  Levis  (1989). 

The  objective  of  an  air  interdiction  mission  system  is  to  plan  operations  against  the  enemy's 
military  potential  before  it  can  be  effectively  used  against  friendly  forces.  These  operations 
restrict  the  combat  capability  of  the  enemy  by: 

•  delaying,  disrupting,  or  destroying  his  lines  of  communications 

♦  destroying  enemy  supplies 

•  attacking  fixed,  moving  and  movable  point  and  area  targets 

♦  destroying  unengaged  or  uncommitted  enemy  attack  formations  before  they  can 
be  brought  into  the  battle. 

The  result  of  these  operations  is  to  disrupt  enemy  plans  and  time  schedules.  The  integration 
of  air  interdiction  operations  with  the  fire  and  maneuver  plans  of  surface  forces  is  not  required. 
However,  these  offensive  air  operations  are  planned  and  conducted  as  part  of  the  unified  effort  of 
all  friendly  forces,  Therefore,  air  interdiction  demands  precise  coordination  and  timing. 

5.1  FUNCTION  IDENTIFICATION 

The  identification  of  the  functions  of  the  system  requires  the  examination  of  the  context  and 
the  environment  in  which  the  system  operates.  The  context  consists  of  the  geographical 
characteristics  or  the  battle  area.  It  is  assumed  that  the  system  is  operating  in  Europe,  and  more 
specifically  in  the  central  region.  The  environment  consists  of  the  friendly  forces,  their  assets, 
strength,  current  plans  and  orders,  the  enemy  forces,  their  assets,  strength,  current  plans  and 
orders.  Also,  the  current  weather  is  part  of  the  environment  as  it  is  a  particularly  important  factor 
m  air  interdiction  mission  planning.  The  functions  needed  to  plan  tin  Air  Interdiction  Mission  are 
listed  in  Table  5.1 .  These  functions  are  described  further  in  this  chapter. 
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For  each  function,  subfunctions  have  been  defined.  Some  of  them  are  used  in  different 
functions  and  for  the  purpose  of  clarity,  a  unique  identification  number  has  been  assigned  to  each 
one  which  is  used  consistently  in  the  figures  and  tables.  The  list  is  given  in  Table  5.2. 


Table  5.1  System  Functions  of  MESACC 


formation  Fusion/Update  Databas 


Funcuon  #  i  Description 


Weather  Projection 


tatus  or  Allied  Forces _ 

Strike  Assesment 


rat  Assesment 


Current  Intelligence 


_ / _ i  Target  Dcvclopmcnt/Pnonuzaijon _ _ _ 

8  iAimpointConstnjctioa'Wcaponccnng 


ttnuon  Analysis 


Mission  Planning 


n  Svsicm  Availabilr 


Uaaltan 


Table  5.2  Subfunctions  used  in  MESACC 


•Suhfnnction  Description 

Subfunction  ft 

Descnpuon 

1 

Acknowledge 

27 

Request  Stnkc  Assessment  Data 

i  2 

!  3 

Request  Weather  Data 

28 

Get  Strike  Assessment  Data 

Get  Weather  Data 

29 

Assess  Strike 

4 

Deduce  Weather  Proiccuon 

30 

1  '  5 

Update  Weather  Data  Base 

31 

Request  Strike  Report 

6 

Request  Weather  Proiccuon 

32 

Generate  Stnke  Report 

;  / 

Get  Weather  Projection 

33 

Request  Threat  Assessment  Data 

|  8 

Request  Allied  Data 

34 

Get  Threat  Assessment  Daia 

Get  Allied  Forces  Data 

35 

Update  Threat  Assessment  DataBase 

10 

Fuse  Allied  Forces  Information 

36 

Modify  Threat  Assessment 

:  1 1 

Update  Allied  Forces  DataBase 

37 

Rank  Threats 

;  i: 

Determine  Allied  Status 

38 

Request  Targets  List 

!  13 

Request  Allied  Report 

39 

Get  Targets  list 

1J 

Gel  Allied  Report 

40 

Request  Available  W'capons 

15 

Request  Enemy  Forces  Data 

41 

Get  Available  weapons 

16 

i  IT" 

Get  Enemy  Forces  Data 

t.  42  - 

Request  Weapon  Data 

Fuse  Enemy  Forces  Information 

43 

Get  Weapon  Data 

|  _18 _ 

Update  Enemv  Forces  DataBase 

Generate  new  Weapon  status 

Request  Enemy  Report 

45 

Generate  List  of  Available  W 'capons 

L  ?0  _ 

46 

Request  Current  Intelligence 

47 

Get  Current  Intelligence 

:  22 

Get  Battlefield  Data 

48 

Aimpoint  Construction  Weaponcering 

23  \  fuse  Battlefield  Information 

49 

Perform  Analysis 

i _ 24  __ 

Update  Battlefield  DataBase 

7T"50  ........ 

Request  Penetration  Analysis 

i  25 

Request  Battlefield  Report 

51 

Get  Penetration  Analysis 

i . . ^ _ 

Generate  Battlefield  Report  ____ 

52 

Plan  Mission 
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ACTOR  IDENTIFICATION 


5.2 

For  the  identification  of  the  actors,  eleven  workstations  (\VS)  are  considered,  located  in  two 
shelters,  and  seven  databases.  In  addition,  the  intelligence  center  is  considered  as  an  actor 
providing  the  latest  information  about  the  situation.  In  this  example,  databases  are  considered  to 
be  actors  because  they  are  distributed  and  exchanges  have  to  take  place  on  the  network  to  access 
them.  These  seven  databases  are: 

•  DB-wt:  contains  weather  forecasts  that  come  from  the  weather  repons  and  which  are 
produced  by  fl. 

•  DB-wp:  contains  data  about  weapons  availability,  given  the  status  of  the  allied  equipment, 
and  the  weather  forecasts. 

•  DB-en:  contains  data  about  tlu  enemy  . 

•  DB-ba:  contains  data  about  the  situation  on  the  battle  field. 

•  DB-st:  contains  data  about  strike  assessment,  i.e.,  the  result  of  f4. 

•  DB-th:  contains  data  about  threat  assessment,  i.e.,  the  results  of  f5. 

•  DB-al:  contains  data  about  the  allied  forces. 

There  are  therefore  nineteen  actors  listed  in  Table  5.3  with  their  corresponding  notation. 


Table  5.3  The  Nineteen  Actors  of  N1ESACC 


5.3  RESPONSIBILITIES  SPECIFICATION  FOR  EACH  FUNCTION 


The  responsibilities  specification  for  each  function  is  made  by  allocating  roles  to  different  the 
different  actors  involved  in  its  execution. 


5.3.1  Function  1:  Weather  Projection 


This  function  forecasts  the  weather  from  the  current  weather  reports. 

When  WS1  receives  a  weather  report,  he  accesses  the  weather  database  (subfunctions 
"Request  Weather  Data"  and  "Get  Weather  Data")  to  get  the  relevant  data  to  make  the  new 
weather  projection  (subfunction  "Deduce  Weather  Projection").  He  updates  the  database  with  this 
new  weather  projection  (subfunctions  "Update  Weather  Database"  and  'Acknowledge").  Table 
5.4  shows  the  responsibility  plane  for  the  function  fl.  The  Petri  Net  is  shown  on  Figure  5.1. 


Table  5.4  Responsibilities  for  Function  fl 


f  1  Weather  Projection 

Actor# 

1 

13 

Subi> 

Subfunction 

Actor 

wsi 

Db-wi 

_  *i 

Request  Weather  Data 

E 

A 

!  3 

C 

E 

i  4 

E 

5i  Update  Weather  Data  Base 

E 

1!  Acknowledge 

r  c 

E 

1.2E1  1 .30 1  1.4E1  1.5E1  MCI 


Figure  5.1  Petri  Net  for  Function  fl 


5.3.2  Function  2:  Format  Messages/Fusion  of  Information/Update  Databases 

This  function  transforms  the  format  of  the  various  data  inputs  into  a  common  format.  The 
function  also  performs  decoding.  Then,  this  function  updates  the  current  information  as  new 
messages  come  in  the  system.  For  example,  if  the  database  contains  the  position  of  a  particular 
enemy  battalion,  arid  later  an  intelligence  report  confirms  that  the  battalion  has  moved  to  another 
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position,  then  the  function  is  used  to  update  the  position  of  that  battalion,  its  strength,  and  current 
plans. 

WS1 1  takes  care  of  repons  about  allied  forces,  while  WS7  deals  with  repons  about  the 
enemy  forces  and  WS8  with  the  battlefield  situation.  They  work  concurrently.  When  they  receive 
repons,  they  have  to  access  the  database  to  get  the  relevant  data  about  the  situation  (subfunctions 
"Request  Allied  Forces  Data"  and  "Get  Allied  Forces  Data"  for  WS1 1,  "Request  Enemy  Forces 
Data"  and  "Get  Enemy  Forces  Data"  for  WS7,  "Request  Battlefield  Data”  and  "Get  Battlefield 
Data"  for  WS8)  to  infer  the  new  situation  with  the  new  information  received  (subfunctions  "Fuse 
Allied  Forces  Information"  for  WSll,  "Fuse  Enemy  Forces  Information”  for  WS7,  "Fuse 
Battlefield  Information"  for  WS8).  This  situation  is  then  stored  in  the  database  (subfunctions 
Update  Allied  Forces  Database"  and  "Acknowledge"'  for  WSll,  "Update  Enemy  Forces 
Database"  and  "Acknowledge"  for  WS7,  "Update  Battlefield  Database"  and  "Acknowledge"  for 
WS8).  The  Responsibility  plane  for  the  function  f2  is  shown  on  Table  5.5  and  the  corresponding 
Petri  Net  is  displayed  on  Figure  5.2. 


Table  5.5  Responsibilities  for  Function  f2 
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1 

E 

] 
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■ 

wm 

E 

mm 
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c 

mm 

15 

Request  Enemy  Forces  Data 
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■  1 
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id 

Get  Enemy  Forces  Data 

mm 

E 

i 

p 

E 

.  f 

- 1 

!  >8 

Update  Enemy  Forces  DataBase 

E 

A 

— . --- 

_  J 

l 

Acknowledge 

c 

E 

21 

Request  Battlefield  Data 

E 

A 

. -  - 

22 

Get  Battlefield  Data 

■ 

C 

E 

23 

Fuse  Battlefield  Information 

mm 

E 

24 

Update  Battlefield  DataBase 

E 

A 

1 

Acknowledge 

C 

E 

r 

_ 
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2.15E7  2.16C7  2.17E7  2.18E7  2.1C7 


2.21E8  2.22C8  2.23E8  2.24E8  2.1C8 


2.8E11  2.9C11  2.10E11  2.11E11  3.1C11 


Figure  5.2  Petri  Net  for  Function  f2 
5.3.5  Function  f3:  Status  of  Allied  Forces. 


This  function  is  used  to  assess  the  current  state  of  the  allied  forces,  number  of  troops, 
equipment,  and  of  available  aircraft  for  missions. 

To  determine  the  status  of  allied  forces,  Workstation  W'S7  needs  to  get  information  from  the 
battlefield  and  to  deduce  from  the  last  state  of  the  allied  forces  the  new  status.  Therefore,  WS8  is 
queried  to  obtain  a  battlefield  report  (subfunction  "Request  Battlefield  Report").  To  do  this,  W'S8 
has  to  access  the  database  Battlefield  (subfunctions  "Request  Battlefield  Data"  and  "Get 
Battlefield  Data")  to  make  the  report  that  it  sends  to  WS7  (subfunction  "Generate  Battlefield 
Report")-  According  to  the  data  that  W’S7  has  just  received,  WS7  accesses  the  allied  forces  data 
base  (subfunction  "Request  Allied  Data"  and  "Get  Allied  Data”)  to  determine  the  new  status  of 
the  allied  forces  (subfunction  "Determine  Allied  Status").  Once  this  is  performed,  the  allied 
forces  database  has  to  be  updated  (subfunctions  "Update  Allied  Forces"  and  "Acknowledge"). 
The  responsibility  analysis  plane  is  shown  on  Table  5.6  and  the  Petri  Net  deduced  from  this 
responsibility  analysis  plane  is  displayed  on  Figure  5.3. 
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Table  5.6  Responsibilities  for  Function  f3 


B  Status  of  Allied  Forces  i  Actor#  |  7 

8 

16  i  !9 

Subf#  i  Subtuncuon  i  Actor 

WS7 

WS8 

DB-ba 

DB-al 

25i  Request  Battlefield  Report 

E 

A 

211  Request  Battlefield  Data 

E 

__ 

A 

22j  Get  Battlefield  Data 

C 

E 

■  ■ 

261  Generate  Battlefield  Report 

C 

E 

■  ■ 

8j  Request  Allied  Data 

E 

A 

9j  Get  Allied  Forces  Data 

C 

E 

1Z  Determine  Allied  Status 

E 

■  ■ 

1  li  Update  Allied  Forces  DataBase 

E 

. 

mm 

l!  Acknowledge 

C 

E 

3.25E7  3.26C7  3.8E7  3.9C7  3.12E7  3.11E7  3.1C7 


5.3.4  Function  4:  Strike  Assessment 

This  function  updates  the  situation  on  the  battlefield,  as  a  result  of  previous  air  interdiction 
missions. 

WS8  accesses  the  Strike  Assessment  Database  to  get  the  last  assessment  made  (subfuncnons 
"Request  Strike  Assessment  Data'"  and  "Get  Strike  Assessment  Data").  He  then  queries  WS7  to 
get  a  report  on  the  enemy  forces  (subfunction  "Request  Enemy  Report").  WS7  accesses  the 
Enemy  Forces  Database  (subfunctions  "Request  Enemy  Forces  Data"  and  "Get  Enemy  Forces 
Data")  to  make  the  report  he  sends  to  WS8  (subfunction  "Generate  Enemy  Report").  Then,  WS8 
has  to  access  the  Threat  Assessment  Database  (subfunctions  "Request  Threat  Assessment  Data” 
and  "Get  Threat  Assessment  Data")  to  check  what  threats  have  been  destroyed  or  what  new  threat 
has  appeared.  From  all  the  information  he  can  then  assess  the  result  of  previous  air  interdiction 
missions  and  what  remains  to  be  done  (subfunction  "Assess  Strike").  WS8  finally  stores  these 
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information  in  the  Strike  Assessment  Database  (subfunctions  "Update  Strike  Assessment 
Database").  The  responsibility  analysis  plane  is  shown  on  Table  5.7  and  the  Petri  Net  derived 
from  this  responsibility  analysis  plane  is  displayed  on  Figure  5.4. 


Table  5.7  Responsibilities  for  Function  f4 
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A 
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Figure  5.4  Petri  Net  for  Function  f4 


5.?. 5  Function  5:  Threat  Assessment 

This  function  evaluates  the  threat  of  the  enemy  forces  in  the  different  sectors  of  the 
battlefield. 

To  make  the  threat  assessment,  WS9  needs  to  get  the  last  threat  assessment  from  the  Threat 
Assessment  Database  (subfunctions  "Request  Threat  Assessment  Data"  and  "Get  Threat 
Assessment  Data").  He  asks  WS7  to  report  on  the  enemy  forces  (subfunctions  "Request  Enemy 
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Report",  "Request  Enemy  Forces  Data",  "Get  Enemy  Forces  Data"  and  "Generate  Enemy 
Report")  and  WS8  to  report  on  the  battlefield  situation  tsubfuncttons  'Request  Battlefield 
Report".  "Request  Battlefield  Data",  "Get  Battlefield  Data"  and  "Generate  Battlefield  Report"). 
From  these  reports,  he  can  build  a  list  of  the  threats  that  he  stores  in  the  Threat  Assessment 
Database  (subfunctions  "Update  Threat  Assessment  Database",  and  "Acknowledge").  The 
responsibility  analysis  plane  is  shown  on  Table  5.8  and  the  derived  Petri  Net  is  displayed  on 
Figure  5.5. 


Table  5.8  Responsibilities  for  Function  f5 
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Figure  5.5  Petn  Net  for  Function  f5 


63 


5.3.6  Function  6:  Current  Intelligence 


Under  certain  circumstances,  repons  from  intelligence  may  be  requested  when  the 
uncertainty  about  some  parameters  of  the  problem  is  deemed  too  high. 

If  the  information  contained  in  the  databases  is  not  sufficient  to  make  the  threat  assessment, 
\V'S9  can  ask  the  Intelligence  Center  (INC)  (subfunctions  "Request  Current  Intelligence"  and 
"Get  Current  Intelligence"),  if  it  has  any  current  intelligence  on  the  battlefield  situation.  With  this 
new  information,  WS9  can  then  modify  the  threat  assessment  (subfunction  "Modify  Threat 
Assessment").  The  responsibility  analysis  plane  is  shown  on  Table  5.9  and  the  Petri  Net  deduced 
from  this  responsibility  analysis  plane  is  displayed  on  Figure  5.6. 


Table  5.9  Responsibilities  for  Function  f6 


f6  Curreni  Intelligence 

Actor# 

9 

12 

Subf#|  Subfuncuon 

Actor 

WS9 

INC  ! 

46!  Request  Current  Intelligence 

E 

— 

47j  Get  Current  Intelligence 

c 

E 
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E 
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Figure  5.6  Petri  Net  for  Function  f6 
5.3.7  Function  7:  Target  Priontization/Target  Development 

This  function  is  needed  to  prioritize  the  most  important  objective  to  be  destroyed,  given  the 
situation.  The  resources  that  can  be  used  for  the  next  mission  may  be  scarce  so  that  it  may  not  be 
possible  to  allocate  assets  to  all  objectives. 

To  do  this,  W'S2  needs  to  get  the  threat  list  from  the  Threat  Assessment  Database 
(subfunctions  "Request  Threat  Assessment  Data"  and  "Get  Threat  Assessment  Data").  WS2 
needs  also  a  report  on  the  situation  on  the  battlefield  (subfunction  "Request  Battlefield  Report") 
that  he  asks  WS6.  who  has  to  access  the  Battlefield  Database  (subfunctions  "Request  Battlefield 
Data"  and  "Get  Battlefield  Data"),  to  generate  this  report  (subfunction  "Generate  Battlefield 
Report").  Once  WS2  receives  this  report,  he  can  rank  the  threats  according  to  the  current 
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Situation  tsubfunction  "Rank  Threats'  ).  The  responsibility  analysis  plane  is  shown  on  Table  5. 10 
and  the  Petri  Net  deduced  from  this  responsibility  analysis  plane  is  displayed  on  Figure  5.7. 

Table  5.10  Responsibilities  for  Function  f7 
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Figure  5.7  Petri  Net  for  Function  f7 


5.?. 8  Function  8:  Aimpoint  Construction/  Weaponeering 


This  function  provides  the  coordinates  of  the  target,  and  allocates  certain  classes  of  friendly 
assets  according  to  the  objective  and  its  intrinsic  characteristics.  WS4  is  in  charge  of  executing 
this.  The  responsibility  analysis  plane  is  shown  on  Table  5.11  and  the  Pern  Net  deduced  from 
this  responsibility  analysis  plane  is  displayed  on  Figure  5.8. 


Table  5.1 1  Responsibilities  for  Function  f8 
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Figure  5.8  Petri  Net  for  Function  f8 


5.3.9  Function  9:  Penetration/Attrition  Analysis 


This  function  forecasts  the  degree  of  redundancy  that  is  adequate  for  each  objective. 
Different  platforms  may  be  assigned  the  same  objective  to  protect  friendly  assets.  Therefore, 
redundancy  insures  a  greater  degree  of  certainty  over  the  outcome  of  the  mission. 

The  penetration/attrition  analysis  is  performed  by  WS3.  To  do  this,  he  needs  a  report  on  the 
position  of  the  enemy  that  he  obtains  from  WS10  (subfunctions  "Request  Enemy  report", 
"Request  Enemy  Forces  Data",  "Get  Enemy  Forces  Data"  and  "Generate  Enemy  Report  "j.  The 
Strike  Assessment  report  that  WS3  asks  from  WS6,  allows  him  to  know  to  what  extent  the 
defenses  of  the  enemy  have  been  reduced  as  a  result  of  previous  missions  (subfunctions 
"Request  Strike  report",  "Request  Strike  Assessment  Data",  "Get  Strike  Assessment  Data"  and 
"Generate  Strike  Report ").  Finally,  to  avoid  to  harm  to  allied  forces,  he  needs  to  know  their 
position  (subfunctions  "Request  Allied  Forces  Data"  and  "Get  Allied  Forces  Data")  before 
performing  the  analysis  (subfunction  "Perform  Analysis").  The  responsibility  analysis  plane  is 
shown  on  Table  5.1?  and  the  Petri  Net  deduced  from  this  responsibility  analysis  plane  is 
displayed  on  Figure  5.9. 


Table  5.12  Responsibilities  for  Function  f9 
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Figure  5.9  Petri  Net  for  Function  f9 
5.3.10  Function  10:  Mission  Planning 

This  function  delivers  the  final  output  of  the  system  to  the  environment.  It  consists  of  a  set 
of  missions  with  the  objectives,  the  type  of  aircraft  to  be  used,  the  armament,  the  number  of 
aircraft  to  be  used  for  each  objective,  the  route  to  be  followed,  and  the  time  to  perform  the 

mission. 

WS4  is  in  charge  of  planning  the  mission  and  generate  the  order.  He  asks  WS2  for  the 
targets  list  (subfunctions  "Request  Targets  List"  and  "Get  Targets  List").  He  needs  to  know  from 
WS5  what  weapons  systems  are  available  (subfunctions  "Request  Available  Weapons"  and  "Get 
Available  Weapons")  and  also  the  weather  projection  from  WS1  (subfunctions  "Request 
Weather  Projection'  and  "Get  Weather  Projection")  to  determine  what  type  of  missions  are 
possible.  The  penetration  analysis  given  to  him  by  WS3  (subfunctions  "Request  Penetration 
Analysis"  and  "Get  Penetration  Analysis")  allows  to  select  the  targets  and  to  plan  the  mission 
(subfunction  "Plan  Mission").  The  responsibility  analysis  plane  is  shown  on  Table  5.13  and  the 
Petri  Net  deduced  from  this  responsibility  analysis  plane  is  displayed  on  Figure  5.10. 
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Table  5.13  Responsibilities  for  Function  f  10 
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Figure  5.10  Petri  Net  for  Function  flO 


5.3.1 1  Function  1 1:  Weapon  System  Availability 

This  function  describes  what  weapons  are  available  for  the  mission  at  the  time  it  is  planned. 
This  function  tells  what  is  available  according  to  the  weather  forecasts  (some  aircraft  cannot  fly 
under  certain  circumstances),  and  the  status  of  the  allied  forces  (losses,  use  of  reserves). 

WS5  gets  from  the  Weapon  Database  the  last  weapon  status  (subfunctions  "Request 
Weapon  Data"  and  "Get  Weapon  Data").  The  report  on  the  allied  status  that  he  asks  from  WS10 
(subfunctions  "Request  Allied  report",  "Request  Allied  Data"  Get  Allied  Data"  and  "Generate 
Allied  Report")  allows  him  to  check  what  has  been  damaged  and  to  generate  a  new  weapon  status 
that  he  stores  in  the  Weapon  Database  (subfunctions  "Generate  New  Weapon  Status"  and 
"Acknowledge").  The  weather  data  he  gets  from  the  Weather  Database  (subfunctions  "Request 
Weather  Data"  and  "Get  Weather  Data")  allows  him  to  generate  a  list  of  available  w  eapons  that 
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can  be  used  in  the  current  weather  situation  (subfunction  'Generate  List  of  Available  Weapons"). 
The  responsibility  analysis  plane  is  shown  on  Table  5.14  and  the  Petri  Net  deduced  from  this 
responsibility  analysis  plane  is  displayed  on  Figure  5.1 1. 


Table  5.14  Responsibilities  for  Function  f  1 1 
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Figure  5.1 1  Petri  Net  for  Function  fl  1 
5.4  GENERATING  THE  DETAILED  REQUIREMENTS 
5.4.1  Global  Requirements 

A  specific  scenario  is  considered  next.  It  is  assumed  that  the  hostilities  started  two  days  ago. 
Although  the  enemy  has  gained  ground  on  the  battlefield,  the  friendly  forces  resist  the  pressure. 
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and  major  assets  in  reserve  have  not  been  committed  on  either  side,  The  conflict  is  a  conventional 
one.  The  friendly  forces  and  the  enemy  forces  have  both  fairly  accurate  information  about  the 
situation  on  the  other  side.  Each  side  knows  what  the  resources  are  on  the  opposing  side,  as  well 
as  the  location  of  these  assets,  although  some  uncertainty  remains.  Ln  certain  areas,  the  battle  line 
is  difficult  to  assess.  Therefore,  there  is  a  need  to  use  MESACC  to  plan  long  distance  bombing 
from  high  altitude.  In  this  scenario,  some  functions  are  not  necessary,  such  as  the  "construct 
database"  function.  Since  the  conflict  started  two  days  ago,  the  database  already  exists.  All  the 
other  functions  described  earlier  are  in  use. 

The  various  data  inputs  from  the  sensors  are  weather  reports,  repons  on  friendly  and  enemy 
forces  (strength,  position,  status),  combat  repons,  request  from  the  local  Command  Center  for 
assistance,  mission  reports,  and  current  and  future  operations  plans.  The  output  is  unique  and 
consists  of  air  interdiction  mission  plans.  The  interrelationship  between  the  various  functions  is 
as  follows: 


f4 


fl 


fll 

f9 


flO 


fl 

f3 


>  f? 


fii 

f8 


f4  - >  f9 

f5  - >  f4 


It  should  be  understood  that  this  description  of  the  interrelationship  between  functions  is 
purely  functional.  If  a  function  is  derived  from  another,  it  does  not  mean  that  the  input  of  that 
function  is  sufficient.  Indeed,  data  from  the  context  may  be  necessary  (terrain  information  for 
example).  The  global  functional  requirements  of  MESACC  are  described  by  the  Petri  Net  of 
Figure  20.  This  Petri  Net  contains  only  one  switch,  si,  which  represents  the  optional  use  of  the 
"Current  Intelligence"  function,  f6. 
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Figure  5.!  2  MESACC:  The  Global  Functional  Requirements 


5.4.2  Detailed  Requirements 

The  Petri  Net  obtained  from  the  global  functional  requirements  is  used  to  determine  the 
slices  of  the  Net.  The  slices  are: 

Slice  1:  fl.  f2. 

Slice  2;  f3,  f5. 

Slice  3:  f6. 

Slice  4:  f4.fl  1. 

Slice  5:  f7,  f9. 

Slice  6:  f8. 

Slice  7:  flO. 

To  determine  how  data  are  transmitted  among  functions,  Cube  Tool  has  to  be  applied  once 
more.  The  purpose  is  to  define  the  global  responsibility  for  the  scenario.  In  the  definition  of  the 
responsibilities  for  each  function,  only  one  actor  triggers  the  execution  and  gets  the  final  report. 
By  looking  at  the  global  .unctional  requirements,  and  at  the  different  responsibility  planes,  one 
can  identify  where  the  output  of  each  function  has  to  be  sent  in  order  to  generate  the  Scenario 
Responsibilities  Plane  showi  on  Table  5. 1 5.  The  Petri  Net  of  the  scenario  is  deduced  and  shown 
on  Figure  5.13. 
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Table  5.15  Scenario  Responsibilities 
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The  representation  of  the  detailed  requirements  is  obtained  (1)  by  replacing  each  transition 
containing  the  letter  E  with  the  Petri  Net  representation  of  the  responsibilities  of  the  functions  this 
role  E  models  and  (2)  by  adding  the  implicit  information  exchanges  between  the  functions 
performed  by  a  single  actor.  Figure  5.14  displays  the  detailed  requirements  of  MES ACC. 
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CHAPTER  6 


CONCLUSION  AND  DIRECTIONS  FOR  FUTURE  RESEARCH 

6.1  CONCLUSION 

Cube  Tool  has  been  extended  from  functions  to  systems.  A  methodology  for  deriving 
structural  requirements  has  been  proposed.  Cube  Tool  allows  to  define  the  functions  and  how  the 
various  tasks,  both  processing  and  communications,  are  allocated  to  the  different  actors  of  the 
system  and  how  these  actors  interact.  The  Cube  Tool  Responsibility  Analysis  plane  is  the  basis 
for  generating  the  Petn  Net  of  the  responsibilities  for  each  function.  These  nets  are  merged 
according  to  certain  rules  to  obtain  a  representation  of  the  scenario-dependent  requirements  w  hich 
include  the  processes  and  the  communications.  Different  modes  can  be  taken  into  consideration 
by  using  Colored  Petri  Nets.  This  methodology  fills  a  gap  between  the  description  of 
requirements  and  the  quantitative  models  needed  for  the  analysis  and  evaluation  of  C31  system 
designs. 

6.2  DIRECTIONS  FOR  FUTURE  RESEARCH 

For  future  research  several  directions  can  be  followed.  The  first  one  is  to  generate 
architectures  from  the  Petn  Net  representation  of  the  requirements.  "Actor"  is  a  generic  term  for  a 
set  of  human  and  hardware/software  resources  located  at  a  specific  place.  The  architecture 
generation  process  will  be  to  define  in  more  detail  how  the  activities  performed  by  a  given  actor 
can  be  distnbuted  among  the  different  available  resources.  This  will  require  the  addition  of  some 
resource  places  on  the  requirements  net. 

Once  this  is  done,  the  System  Effectiveness  Analysis  methodology  can  be  applied  to  make 
Cube  Tool  a  complete  tool  for  designing  C3I  systems.  For  each  of  the  architectures  obtained, 
measures  of  performance  can  be  evaluated  to  determine  the  effectiveness  of  a  system.  These 
measures  of  effectiveness  w  ill  be  another  criterion  for  selecting  the  system  to  be  built. 

Another  direction  is  to  improve  the  methodology  of  Valraud  and  Levis  (1989)  for  comparing 
a  system  with  its  requirement  with  the  Petri  Net  of  the  requirements  obtained  by  using  the 
procedures  described  in  this  report.  The  Petri  Net  representation  of  a  system  is  compared  to  a 
Petri  Net  representation  of  the  requirements  which  only  desenbes  the  interrelationships  among 


processes.  By  using  the  detailed  Petri  Net  of  the  requirements,  a  more  accurate  view  of  the 
shortfalls  and  overlaps  can  be  obtained. 
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